CMake/meson fixes, Windows support for shared lib build #1225

BalkanMadman · 2025-11-01T17:08:22Z

Hello!

We've been packaging QuickJS-ng in Gentoo and we've found meson to be the most versatile amongst the added build systems. Huge thanks for taking care of QuickJS and implementing modern build systems -- it makes the life of us, packagers, much much easier.

This PR bundles two simple fixes for meson.build

meson.build

BalkanMadman · 2025-11-04T19:22:06Z

As far as I'm aware, the CI failures are not caused by these changes

BalkanMadman · 2025-11-18T17:06:21Z

Ping. Any updates?

saghul · 2025-11-18T19:29:37Z

I've triggered the CI again. IIRC the failures were directly related to this change, but let's see.

bnoordhuis · 2025-11-18T19:29:48Z

I'm fine with this change. @saghul?

edit: cross-wired

BalkanMadman · 2025-11-19T01:22:13Z

I've been going through CI and stumbled upon this: https://github.com/quickjs-ng/quickjs/actions/runs/19475324220/job/55744866380?pr=1225#step:7:42

meson.build:624: WARNING: Trying to use ['address', 'undefined'] sanitizer on Clang with b_lundef.

BalkanMadman · 2025-11-19T01:22:35Z

I can reproduce the failure on my machine too (albeit with clang only).

BalkanMadman · 2025-11-19T01:25:23Z

https://github.com/google/sanitizers/wiki/AddressSanitizer#faq:

Q: When I link my shared library with -fsanitize=address, it fails due to some undefined ASan symbols (e.g. asan_init_v4)?

A: Most probably you link with -Wl,-z,defs or -Wl,--no-undefined. These flags don't work with ASan unless you also use -shared-libasan (which is the default mode for GCC, but not for Clang).

BalkanMadman · 2025-11-19T01:25:58Z

Meson option b_lundef defaults to true, e.g. -Wl,--no-undefined is added to CFLAGS.

BalkanMadman · 2025-11-19T01:42:01Z

Passing -shared-libasan seems to fix the error.

BalkanMadman · 2025-11-19T02:35:37Z

Should fix the CI.

saghul · 2025-11-19T11:08:06Z

Yeah so as I said, the meson CI needs updating now to statically link by default.

BalkanMadman · 2025-11-21T20:09:24Z

Would you like to me to do the CI update (including the fix for the failing CI for this PR) in this PR or separately?

saghul · 2025-11-21T20:33:59Z

Would you like to me to do the CI update (including the fix for the failing CI for this PR) in this PR or separately?

In this PR please, we like to avoid merging failing PRs.

BalkanMadman · 2025-11-22T21:41:09Z

Would you like to me to do the CI update (including the fix for the failing CI for this PR) in this PR or separately?

In this PR please, we like to avoid merging failing PRs.

Your release CI builds QuickJS-NG with CMake so this PR shouldn't affect that. ~~The PR already contains a fix for PR CI.~~ My apologies, screwed up the quoting

BalkanMadman · 2025-11-22T22:05:42Z

Apparently, for MSVC CI, we're hitting mesonbuild/meson#13892. Will add a commit forcing MSVC-based builds to use static libs.

bnoordhuis · 2025-12-20T18:53:28Z

@BalkanMadman ping, seems this was close to done?

BalkanMadman · 2025-12-24T06:30:05Z

Hello! Sorry for the delay, could you please try running the CI again? The two new commits should fix two issues in building QuickJS-NG shared.

quickjs.h

BalkanMadman · 2025-12-24T09:09:16Z

Okay, I also need to guard all the dll{export,import} shenanigans if we're building static libqjs🔥🔥🔥

Because obviously just exporting symbols isn't enough and on Windows you need separate exports for DLLs and static libs👍

saghul · 2025-12-24T12:25:12Z

Not sure I get the unconditional define in quickjs.c. Shouldn't it be set by Meson depending on the build type?

saghul · 2025-12-26T11:53:58Z

Looks like there are conflicts, can you rebase?

quickjs.h

saghul · 2026-01-06T16:46:06Z

quickjs.h

+#endif /* QUICKJS_NG_PLAT_WIN32 */
+
+/*
+ * `JS_LIBC_EXTERN` -- helper macro that must be used to mark the extern


Is there a problem if we don't use this and simply use JS_EXTERN directly in the libc?

We can't do that when libc isn't built as a part of shared qjs.dll on Windows.

In this case, in quickjs-libc, we need JS_LIBC_EXTERN to be empty, while JS_EXTERN is __declspec(dllexport) (for qjs) or __declspec(dllimport) (for qjs consumers). Both break libc's builds on Windows.

For all other cases, it doesn't make much sense to duplicate all the logic.

What I mean, is that we need to have some additional logic for specifically the libc version of JS_EXTERN in any case.

And, to me, overloading JS_EXTERN for that doesn't seem to be the most ergonomic solution.

Not sure I fully follow. Both when built as static and shared library the libc is part of the core library build so it should follow the same rules.

Easy: #1312

Apropos the dllimport/dllexport dichotomy, in libuv we solve that like this:

https://github.com/libuv/libuv/blob/91ae02a63d25caccddd835fb201195fefe9d113b/include/uv.h#L34-L46

In a nutshell: it's up to the first party/third party build script to set BUILDING_UV_SHARED or USING_UV_SHARED.

Easy: #1312

Oh, I didn't actually bother to check whether the ptrs are used in one place or all over the libc.

Apropos the dllimport/dllexport dichotomy, in libuv we solve that like this:

https://github.com/libuv/libuv/blob/91ae02a63d25caccddd835fb201195fefe9d113b/include/uv.h#L34-L46

In a nutshell: it's up to the first party/third party build script to set BUILDING_UV_SHARED or USING_UV_SHARED.

That's what's done in this PR, albeit in a bit different way (inspired by zlib). In contrast to libuv, I added one macro for shared qjs (either building or using) — QUICKJS_NG_DLL — and one macro for when qjs is built: QUICJS_NG_QJS_INTERNAL.

I think that as a user definable macro, QUICKJS_NJ_DLL sounds better than USING_SHARED_QJS but that's just my style preference and I can change the macro names.

Any thoughts on this?

Functions declared by cutils.h are used by most of the source files in the project. However, they are not part of libqjs API and, thus, the functions are not marked as API. Apart from the fact that cutils do not belong in libqjs, since they do not constitute a public API and are just helpers, they break shared qjs.dll builds on Windows where DLLs must explicitly mark their interfaces. As cutils.h does not mark its functions with JS_EXTERN or alike, the Windows linker is unable to resolve references to the cutils functions. This commit makes cutils a separate static library, which is linked with the dependent executables/libraries. Signed-off-by: Zurab Kvachadze <[email protected]>

Previously, irrespective of the setting of -Dlibc, quickjs-libc would be built as a static library. In case -Dlibc=true is set, the static library is linked in libqjs only. In case -Dlibc=false is set, the archive is linked to every quickjs-libc consumer. In the former case (-Dlibc=true), building quickjs-libc as static library introduces useless indirection, since quickjs-libc is going to be linked only to libqjs anyway. CMake just adds the libc's sources to qjs's and calls it a day. This commit changes meson.build. If -Dlibc=true is set, quickjs-libc's sources are compiled as a part of libqjs. If not, it compiled as a static library, as was done before. In both cases, a direct dependency of quickjs-libc has been changed into a `dependency` on qjs_libc_dep which conveniently abstracts both configuration. So, if quickjs-libc needs to be linked to, just add `dependencies: qjs_libc_dep`. Signed-off-by: Zurab Kvachadze <[email protected]>

Previously, if QJS_BUILD_LIBC was false, quickjs-libc would be built with every consumer. This made it harder to specify and trace the dependencies/compiler definitions of quickjs-libc itself. With this change, if -DQJS_BUILD_LIBC=false is passed to CMake, quickjs-libc is built as a normal static library, with its own compiler definitions and dependencies. This changes CMake to match the Meson behaviour. Additionally, since CMake does not allow mixing keyword and non-keyword declarations, this commit adds explicit `PRIVATE` to all `target_link_libraries` declarations. Signed-off-by: Zurab Kvachadze <[email protected]>

Since the macros like JS_EXTERN are used in more than one place, it is quite reasonable and helpful to declare them in one place. Additionally, the Windows support with the __declspec tango was missing. This commit, in addition to reorganising definitions, also plumbs Windows support for the renamed QJS_EXTERN, QJS_LIBC_EXTERN and QJS_FORCE_INLINE. Signed-off-by: Zurab Kvachadze <[email protected]>

BalkanMadman · 2026-01-15T03:20:58Z

Rebased, should be mergeable now.

saghul

LGTM, but I'd like @bnoordhuis to also take a look. Nice work!

BalkanMadman · 2026-01-15T13:31:08Z

The CI failures are because examples/fib.c piggybacks on JS_EXTERN from quickjs.h:

https://github.com/BalkanMadman/quickjs/blob/ecc73f14545fb5723d1531e265f97adf7273803f/examples/fib.c#L64

JS_EXTERN is defined to __declspec(dllimport) because the logic (correctly) concludes that fib.c is a consumer of quickjs.h APIs.

The right way to do it is to define a helper macro like JS_MODULE_EXTERN which properly expands to whatever we need for module, i.e. __attribute__((visibility("default))) or __declspec(dllexport). I don't whether it's better to define this macro in quickjs.h (so that the macro doesn't need to be defined in each module) or in each individual module.

What do you think @saghul @bnoordhuis?

saghul · 2026-01-15T13:33:54Z

JS_MODULE_EXTERN

Sounds good to me!

BalkanMadman · 2026-01-15T13:48:59Z

Would you like that to be defined in quickjs.h or in each module?

saghul · 2026-01-15T14:23:52Z

Would you like that to be defined in quickjs.h or in each module?

I think it would be useful to define it in quickjs.h so that modules can reuse it.

BalkanMadman · 2026-01-15T16:38:54Z

Meson doesn't set -DJS_SHARED_LIBRARY for modules in examples/. Should that be fixed too? Also, what is the purpose of this define?

BalkanMadman · 2026-01-15T16:41:28Z

It was seemingly introduced in fib.c in 91459fb. I don't see a point in it though? Should it just be removed?

saghul · 2026-01-15T18:08:34Z

If it's not used then it can go yeah.

BalkanMadman · 2026-01-16T17:00:56Z

The new commit: e43bb25. The rest of the commits are unchanged. Tested test_fib.js with CMake and meson on Linux, binary modules load and work correctly.

Will now test Windows.

The new macro is a counterpart to JS_EXTERN, but for binary C modules. This commit introduces one more preprocessor define that must be set when building C modules. This commit changes examples/fib.c and examples/point.c to use the new macro, while also removing redundant JS_SHARED_LIBRARY. Additionally, the includes use the angled brackets now since quickjs.h is supposed to be external to the binary modules. meson.build is fixed to properly add the include directory; the manual header copying has also been removed as it is redundant. Signed-off-by: Zurab Kvachadze <[email protected]>

Clang cannot handle building shared libraries with sanitizers and -Wl,--no-undefined (set by default unless explicitly disabled with -Db_lundef=false). This commit prefixes CI in case shared libraries are built with sanitisers. Signed-off-by: Zurab Kvachadze <[email protected]>

During the build, the default library can be overridden via the -Ddefault_library=type flag. Presetting this key in meson.build makes life harder for distributions which almost always want to build shared libraries. Those requiring static libraries can always force that via the aforementioned flag. Signed-off-by: Zurab Kvachadze <[email protected]>

BalkanMadman · 2026-01-16T17:31:05Z

The CI should do better now. Tested on Windows with the just applied changes: everything works.

BalkanMadman · 2026-01-16T18:03:09Z

Two tests in https://github.com/quickjs-ng/quickjs/actions/runs/21075154727/job/60616560614?pr=1225 take a minute each. Is that known/expected?

35/53 quickjs-ng:regexp_ascii           OK              60.86s
36/53 quickjs-ng:regexp_utf16           OK              60.16s

saghul · 2026-01-16T18:05:10Z

Yep.

saghul reviewed Nov 1, 2025

View reviewed changes

meson.build Show resolved Hide resolved

BalkanMadman force-pushed the meson-fixes branch from 82ecdd0 to 3aec58b Compare November 18, 2025 17:30

BalkanMadman force-pushed the meson-fixes branch from 3aec58b to 7b63c89 Compare November 19, 2025 02:35

saghul approved these changes Nov 19, 2025

View reviewed changes

BalkanMadman force-pushed the meson-fixes branch from 7b63c89 to 6cd329f Compare December 24, 2025 06:28

BalkanMadman commented Dec 24, 2025

View reviewed changes

quickjs.h Outdated Show resolved Hide resolved

BalkanMadman force-pushed the meson-fixes branch 2 times, most recently from 5b8d06a to 0cf1f7f Compare December 24, 2025 08:54

BalkanMadman force-pushed the meson-fixes branch from 0cf1f7f to d0fe4c0 Compare December 26, 2025 11:39

BalkanMadman force-pushed the meson-fixes branch from d0fe4c0 to 704fed0 Compare December 26, 2025 12:14

BalkanMadman requested a review from saghul January 5, 2026 14:46

BalkanMadman changed the title ~~meson.build fixes~~ CMake/meson fixes, Windows support for shared lib build Jan 5, 2026

saghul reviewed Jan 6, 2026

View reviewed changes

quickjs.h Outdated Show resolved Hide resolved

quickjs.h Outdated Show resolved Hide resolved

quickjs.h Outdated Show resolved Hide resolved

quickjs.h Show resolved Hide resolved

BalkanMadman force-pushed the meson-fixes branch from 0ec4bae to 8687273 Compare January 6, 2026 15:55

saghul reviewed Jan 6, 2026

View reviewed changes

BalkanMadman force-pushed the meson-fixes branch from 8687273 to 209e830 Compare January 6, 2026 17:31

BalkanMadman added 4 commits January 15, 2026 04:15

BalkanMadman force-pushed the meson-fixes branch from 209e830 to ecc73f1 Compare January 15, 2026 03:17

BalkanMadman requested a review from bnoordhuis January 15, 2026 03:21

saghul approved these changes Jan 15, 2026

View reviewed changes

BalkanMadman force-pushed the meson-fixes branch from ecc73f1 to f44c22c Compare January 16, 2026 16:59

BalkanMadman added 3 commits January 16, 2026 18:29

BalkanMadman force-pushed the meson-fixes branch from f44c22c to 02070fd Compare January 16, 2026 17:30

CMake/meson fixes, Windows support for shared lib build #1225

Are you sure you want to change the base?

CMake/meson fixes, Windows support for shared lib build #1225

Uh oh!

Conversation

BalkanMadman commented Nov 1, 2025

Uh oh!

Uh oh!

BalkanMadman commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BalkanMadman commented Nov 18, 2025

Uh oh!

saghul commented Nov 18, 2025

Uh oh!

bnoordhuis commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BalkanMadman commented Nov 19, 2025

Uh oh!

BalkanMadman commented Nov 19, 2025

Uh oh!

BalkanMadman commented Nov 19, 2025

Uh oh!

BalkanMadman commented Nov 19, 2025

Uh oh!

BalkanMadman commented Nov 19, 2025

Uh oh!

BalkanMadman commented Nov 19, 2025

Uh oh!

saghul commented Nov 19, 2025

Uh oh!

BalkanMadman commented Nov 21, 2025

Uh oh!

saghul commented Nov 21, 2025

Uh oh!

BalkanMadman commented Nov 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BalkanMadman commented Nov 22, 2025

Uh oh!

bnoordhuis commented Dec 20, 2025

Uh oh!

BalkanMadman commented Dec 24, 2025

Uh oh!

Uh oh!

BalkanMadman commented Dec 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

saghul commented Dec 24, 2025

Uh oh!

saghul commented Dec 26, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

saghul Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

BalkanMadman Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BalkanMadman Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BalkanMadman Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

saghul Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

bnoordhuis Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

bnoordhuis Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

BalkanMadman commented Nov 4, 2025 •

edited

Loading

bnoordhuis commented Nov 18, 2025 •

edited

Loading

BalkanMadman commented Nov 22, 2025 •

edited

Loading

BalkanMadman commented Dec 24, 2025 •

edited

Loading

BalkanMadman Jan 6, 2026 •

edited

Loading

BalkanMadman Jan 6, 2026 •

edited

Loading

BalkanMadman Jan 7, 2026 •

edited

Loading

BalkanMadman commented Jan 16, 2026 •

edited

Loading